Questions
7 of 11
1Evaluate this claim: 'Cosine similarity and normalized dot product always produce identical rankings.' What subtlety do candidates often miss here?
2Many candidates assume increasing ef at query time always improves recall with only a linear latency cost. What's misleading about that assumption?
3Why is 'just add more RAM' not always a valid answer to a Qdrant performance question in a system design interview?
4A candidate claims that quantization always speeds up search. Under what conditions might quantization with rescoring actually be slower than searching un-quantized vectors?
5Why can two identical-looking filter queries - one using an indexed field, one using an equivalent but unindexed field - have wildly different performance, even though they return the same results?
6At billion-point scale, how would your indexing and sharding strategy differ from a design that works fine at ten million points?
7How would you architect a system to gracefully degrade - rather than fail outright - when a burst of traffic exceeds provisioned Qdrant capacity?
8What are the limits of a purely payload-filter-based multitenancy model, and at what point would you need to introduce dedicated shards or collections per tenant instead?
9How would you approach re-embedding a multi-billion-point production collection with a new embedding model with zero search downtime?
10When designing a retrieval system that combines dense, sparse, and multivector reranking at extreme scale, what's the single biggest cost driver you'd optimize first, and why?
11If you were asked to design Qdrant's filtered-HNSW search from scratch, what core problem would you need to solve, and what naive approach would you reject first?
QdrantQdrant
Core Concepts
Setup and Basic Use
QueryAPIs
Named Vectors and Multitenancy
Sparse Vectors and Hybrid Search
Snapshots and Backups
Indexing Internals
Internal Architecture
Performance and Optimisation
Security
Error Handling and Debugging
Testing
Design Patterns
Implementation Scenarios
System Design and Scalability
Edge Cases
07 / 11

How would you architect a system to gracefully degrade - rather than fail outright - when a burst of traffic exceeds provisioned Qdrant capacity?

Queuing, load shedding, cheaper fallback queries, and circuit breakers

Graceful degradation has four layers: admission control, request shaping, fallback execution, and circuit breaking. Admission control rejects or delays requests when the system is above a threshold, preventing the overload from cascading. Request shaping queues requests and processes them at a controlled rate, so the burst is absorbed rather than dropped. Fallback execution runs a cheaper version of the query when the full query is too expensive: a lower ef, fewer candidates, no reranking, a smaller result set. Circuit breaking stops sending requests to a dependency that is failing, giving it time to recover rather than hammering it. The combination lets the system serve a degraded but useful response under overload, rather than failing all requests or collapsing entirely. The design must define the degradation levels and the thresholds at which each kicks in, and it must be tested under load to verify that the degradation is graceful.

The mechanism that makes each layer effective is that it reduces the load on the bottleneck resource. Admission control reduces the arrival rate. Queuing smooths the arrival rate. Fallback execution reduces the per-request cost. Circuit breaking reduces the load on a failing dependency. The key insight is that the degradation must be progressive: the system should not jump from full service to no service. It should have intermediate states - slightly reduced quality, then more reduced, then minimal - so that users get a useful response at every level. The thresholds must be based on measurable signals: queue depth, latency, error rate, CPU utilization. The fallback queries must be pre-defined and tested, because a fallback that has not been tested is not a fallback. The circuit breaker must have a recovery policy: when the dependency recovers, the system should return to full service gradually, not all at once, to avoid a second overload.

  1. 1

    Admission control: reject or delay requests when above a threshold.

  2. 2

    Queuing: absorb the burst and process at a controlled rate.

  3. 3

    Fallback query: lower ef, fewer candidates, no reranking, smaller result set.

  4. 4

    Circuit breaker: stop sending to a failing dependency; recover gradually.

  5. 5

    Progressive degradation: multiple levels, not a binary switch.

  6. 6

    Thresholds: based on queue depth, latency, error rate, CPU.

  7. 7

    Pre-defined fallbacks: tested and ready, not improvised.

  8. 8

    Recovery: return to full service gradually to avoid a second overload.

The trade-off is between quality and availability. A system that degrades gracefully serves a worse but useful response under load; a system that does not degrades catastrophically, failing all requests. The common mistakes are: (1) no admission control, so the overload cascades; (2) no fallback queries, so the only option is to fail; (3) a fallback that has not been tested, so it fails when it is needed; (4) a circuit breaker that does not recover gradually, causing a second overload; (5) thresholds that are not based on measurable signals, so the degradation is unpredictable. Version note: the degradation strategies are application-level, but the Qdrant features that enable them - lower ef, fewer candidates, no reranking - are configured via the query parameters. The exact parameters and their effect have changed across Qdrant releases.

javascript

Version-dependent: the query parameters used for fallbacks (ef, limit, quantization, rescoring) have evolved across Qdrant releases. The exact degradation levels and their effect on latency and recall should be measured on your version with your data.

Difficulty: 8/10
Topics: Graceful Degradation, Circuit Breaker, Load Shedding

Scenario Questions

0-2 years experience
  1. 1

    Your search service collapses under a traffic spike. Describe the first degradation layer you would add.

  2. 2

    A teammate says the fix is to add more nodes. Explain why graceful degradation is also needed.

2-5 years experience
  1. 1

    You need to serve a 10x traffic spike without failing requests. Describe the degradation strategy and the fallback queries.

  2. 2

    Your circuit breaker recovers all at once and causes a second overload. Diagnose the cause and describe the fix.

5-8 years experience
  1. 1

    Design a progressive degradation strategy for a search service with a 30ms p99 SLO, including the levels, the thresholds, and the fallbacks.

  2. 2

    You need to test the degradation under load without affecting production. Describe the test environment and the scenarios.

8+ years experience
  1. 1

    Derive the optimal degradation thresholds as a function of the load distribution and the SLO, and explain how you would validate them.

  2. 2

    You are designing a system that must maintain availability under extreme load without manual intervention. Describe the architecture and the control loops.

Follow-up Questions

  • ❓How would you decide the thresholds at which each degradation level kicks in, and how would you validate them under load?
  • ❓If the fallback query returns worse results, how would you communicate the degradation to users without eroding trust?